Dynamic reconfiguration and self-reconfiguration are two of the more advanced forms of field programmable gate array (FPGA) reconfigurability. Dynamic reconfiguration involves the active FPGA being fully or partially reconfigured, while ensuring the correct operation of those active circuits that are not being changed. Self-reconfiguration extends the concept of dynamic reconfigurability. It assumes that specific circuits on the FPGA itself are used to control the reconfiguration of other parts of the FPGA. Both dynamic reconfiguration and self-reconfiguration rely on an external reconfiguration control interface to boot an FPGA when power is first applied or the device is reset.
FIG. 1 is a block diagram of a conventional FPGA 90, which includes input/output (I/O) blocks 102A (each labeled IO) located around the perimeter of the FPGA, multi-gigabit transceivers (MGT) 104A interspersed with the I/O blocks, configurable logic blocks 106A (each labeled CLB) arranged in an array, block random access memory 108A (each labeled BRAM) interspersed with the CLBs, configuration logic 112, configuration interface 114, on-chip processor 92 (labeled PowerPC®) and internal configuration access port (ICAP) 120. Although FIG. 1 shows a relatively small number of I/O blocks, CLBs and block RAMs for illustration purposes. It is understood that an FPGA typically includes many more of these elements. On-chip processor 92 is an IBM PowerPC® 405 processor. FPGA 90 can include more than one of these processors (typically up to four of these processors). FPGA 90 also includes other elements, such as a programmable interconnect structure and a configuration memory array, which are not illustrated in FIG. 1. FPGA 90 is described in more detail in “Virtex-II™ Pro, Platform FPGA Handbook”, (Oct. 14, 2002) which includes “Virtex-II Pro™ Platform FPGA Documentation” (March 2002) “Advance Product Specification,” “Rocket I/O Transceiver User Guide”, “PPC 405 User Manual” and “PPC 405 Processor Block Manual” available from Xilinx, Inc., 2100 Logic Drive, San Jose, Calif. 95124.
In general, FPGA 90 is configured in response to a set of configuration data values, which are loaded into a configuration memory array of FPGA 90 (not shown) from an external memory, e.g., a read-only memory (ROM), via configuration interface 114 and configuration logic 112. Configuration interface 114 can be, for example, a select map interface, a JTAG interface, or a master serial interface. The configuration memory array can be visualized as a rectangular array of bits. The bits are grouped into frames that are one-bit wide words that extend from the top of the array to the bottom. The configuration data values are loaded into the configuration memory array one frame at a time from the external memory via the configuration interface 114.
FIGS. 2-1 and 2-2 are simplified conceptual diagrams of the configuration memory array. The bits of the configuration memory array 100 (and 101) configure, for example, the CLBs 106B, BRAMs 108B, MGTs 104B, and I/Os 102B. In FIGS. 2-1 and 2-2 the labels are chosen so that the configuration memory array elements (with a B suffix) in FIGS. 2-1 and 2-2 correspond to their associated physical components (with an A suffix) in FIG. 1. A frame 122 is a column one bit wide extending from the top of the array 100 to the bottom. A frame is the smallest part of the configuration memory array that can be written to or read from.
The processor block is either a hard-core processor, e.g., processor block 110 of FIG. 2-1 and processor 92 of FIG. 1, such as the PowerPC® of IBM Corp. of Armonk, N.Y., or a soft core processor having CLBs, e.g., processor block 109 of FIG. 2-2, such as the MicroBlaze™ processor core of Xilinx Inc. of San Jose, Calif.
In order to provide self-reconfiguration for the FPGA, the internal configuration access port (ICAP) 120 was added. The ICAP 120 gives access by the FPGA's internal logic (e.g., CLB's 106A and BRAMs 108A) to the configuration memory array 100 (and 101). In other words, one part of the configured FPGA can reconfigure another part of the FPGA. Conventionally, this self-reconfiguration was done by loading pre-generated reconfiguration frames in the BRAM, and using customized logic, over-writing pre-targeted frames in the configuration memory array with these pre-generated reconfiguration frames.
FIG. 3 shows the ICAP module 120 of the prior art. There is an eight bit wide input bus 210 and an eight bit wide output bus 218. The input write signal 212 indicates when there is a read from or write to the ICAP module 120 (where, e.g., write=1 and read=0). Additional inputs include a chip enable signal 214 and a clock signal 216. The busy (done) output signal 220 indicates when data can be received by the ICAP module 120.
FIG. 4 is a simplified format of a data packet 310 sent to the input bus 210 of the ICAP module 120 of FIG. 3. The data packet 310, includes a command portion 312 having an operation (op) code 316, a register address 318, and a word count 320 for the data portion 314, and the data portion 314. The operation code 316 includes commands to the configuration logic 112 to, for example, read from or write to the configuration memory array 100. There are registers in the configuration logic 112, which are identified by register address 318. Further details can be found in Xilinx, Inc. application note, XAPP151, Sep. 27, 2000, titled “Virtex Series Configuration Architecture User Guide.”
There are several disadvantages with using the above custom logic self-reconfiguration approach. First, for example, the approach lacks flexibility, as what is to be reconfigured must be predetermined, i.e., the frames pre-generated and the custom logic set. Second, any changes to the reconfiguration take a significant amount of time, as the modified reconfiguration must be pre-loaded. Third, pre-loading entire frames, when only parts of the frames need to be reconfigured is inefficient. And fourth, more complex dynamic reconfiguration scenarios, such as modifying selected resources, generating parameterized circuits on the fly, relocating partial bitstreams to other locations on the array are very difficult to implement in custom logic.
Accordingly, it would be desirable to have an improved scheme for implementing the self-reconfiguration of an FPGA, which overcomes the above-described deficiencies.